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Abstract — To date there has been much discussion about the 
value of Delay Tolerant Networking (DTN) for space missions. 
Claims of various benefits, based on paper analysis, are good; 
however a benefits statement with empirical evidence to 
support is even better. This paper presents potential and 
actual advantages of using DTN for Earth science missions 
based on results from multiple demonstrations, conducted by 
the Communications, Standards, and Technology Laboratory 
(CSTL) at NASA Goddard Space Flight Center (GSFC). 
Demonstrations included two flight demonstrations using the 
Earth Observing Mission 1 (EO-1) and the Near Earth 
Network (NEN), a ground based demonstration over satellite 
links to the Internet Router in Space (IRIS) payload on 
Intelsat-14, and others using the NASA Tracking Data Relay 
Satellite System (TDRSS). Real and potential findings include 
increased flexibility and efficiency in science campaigns, 
reduced latency in a collaborative science scenario, and 
improved scientist-instrument communication and control. 
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1. Introduction 

The Delay Tolerant Network (DTN) protocol is typically 
associated with Deep Space missions where communication 
links are very slow, have large delays, and can often be 
intermittent. Being a store and forward protocol, it is also 
assumed to only be applicable in a multi-hop environment. 
However, it is the premise of this paper to show, through 
demonstration, the applicability of DTN to other types of 
environments, particularly Low Earth Orbit, Earth Science, 
and single spacecraft missions. Potential benefits were 
explored using flight, ground based over satellite links, and 
high-fidelity lab demonstrations. Sensor webs, operations, 
and asymmetric links are areas which displayed potential 
benefits to missions with DTN usage. 

Sensor Webs: According to NASA’s Direction 2005 & 

Beyond, “NASA will develop new space-based technology 
to monitor the major interactions of the land, oceans, 


atmosphere, ice, and life that comprise the Earth system. 
From there, researchers envision an intelligent and 
integrated observation network comprised of sensors 
deployed to vantage points from the Earth’s subsurface to 
deep space. This ’sensor web’ will provide timely, on- 
demand data and analysis to users who can enable practical 
benefits for scientific research, national policymaking, 
economic growth, natural hazard mitigation, and the 
exploration of other planets in this solar system and 
beyond.” [1] The communications infrastructure must evolve 
in order to support NASA's vision of an integrated 
observation network. Missions typically plan their 
communications system with a single mission in mind, their 
own. Each mission should be viewed as a node in the 
integrated observation network to be able to enjoy the 
practical benefits that sensor web scenarios would afford. 

The IRIS collaborative sensor web demonstration focused on 
the benefits of networking as it relates to areas such as 
autonomous alert mechanisms between nodes, improved 
data collection and measurement precision, event 
synchronization, and onboard and ground agent 

synchronization. Rapid response and distribution of 
information is critical. Autonomous planning and data 
transmission via use of multiple downlink access points is 
required. The manual configuration of sensors as they 
continue to expand will become unmanageable and 
operations costs will surely grow. During this 
demonstration, the store and forward network approach of 
DTN and the routing capability minimized the latency 
between nodes by automatically routing data packets to their 
destination despite intermittent links. 

Improved Operations: The EO-1 spacecraft is an Earth 
imaging observatory with a multispectral land imaging 
instrument onboard that is a significant improvement over 
the Landsat 7 ETM+ instrument. At the end of its science 
mission, NASA Headquarters approved a plan for an 
Extended Mission operations phase, where new technologies 
could be validated. Current EO-1 operations require 
coordination of data transfers across the space link with the 
scheduled ground contacts. This is done manually. DTN 
enables the decoupling of these two activities by allowing 
onboard data to be held in persistent storage until a contact is 
available, at which time it is automatically sent to the 
Command and Data Handling (C&DH) for downlink. 

Because of the large volume of hyperspectral data, it is 
typically down linked at very high rates. The data are stored 



at the ground station for future transmission to the user via 
terrestrial links, or in some cases, physical media. Using 
DTN at the ground station, data can autonomously flow to 
the user as the link permits, removing the need for manual 
intervention. On the forward link, data to be uplinked can be 
sent to the ground station at any time and remain in the 
ground network until the forward link becomes available. 

Asymmetric Links: As Earth Science instruments become 
more advanced, the volume of data generated onboard 
significantly increases. This in turn requires high rate 
downlinks to ensure that all data is returned to the user on 
Earth. Spacecraft avionics currently support hundreds of 
megabytes of downlink capacity between the spacecraft and 
the ground stations. The forward link between the ground 
station and the flight systems however, do not support the 
same level of throughput. 

In the CSTL a test was set up to emulate the conditions of a 
multiple access (MA) user and a S-band single access (SSA) 
user of Tracking Data Relay Satellite (TDRS) with 
asymmetric and simplex links. This was done with actual 
TDRS time. The store and forward capability of DTN as 
well as the networked architecture that supports endpoint 
addressing, enables autonomous routing of data when links 
become available, to any user. The rate buffering of DTN 
allows data to be sent at rates conducive to the network. 

The rest of the paper is organized into individual 
experiments and the benefits observed. Section 2 describes 
the EO-1 demonstration. Section 3 describes the IRIS 
collaborative science demonstration and Section 4 describes 
the TDRS. Section 5 summarizes the findings and discusses 
benefits for earth scientists. Finally, future work is 
described in Section 6. 


2. EO-1 Experiment 

Goddard Space Flight Center successfully demonstrated an 
on-obit DTN node using the EO-1 satellite on December 8- 
10 2010 and February 8-10, 2011 as part of a multi-phase 
demonstration activity sponsored in part by the Delay 
Tolerant Readiness Project, NASA HQ. The general goal of 
the EO-1 demonstration activity was to validate DTN 
technology for Earth Observing and other Low Earth Orbit 
(LEO) missions in order to: 

1 . Understand the implications of implementation for 
flight and ground systems. 

2. Demonstrate benefits of the technology. 

3. Discover new approaches and uses for the DTN 
technology. 

In addition, and specific to EO-1, this demo was expected to 
recover, via DTN, real-time housekeeping telemetry that has 
been lost due to a hardware failure in 2006. 

Among the potential DTN benefits identified for EO-1 were: 

• Decoupling the communication scheduling from 
command & telemetry generation . Current EO-1 
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operations require manual control and coordination 
of uplink and downlink data transfers to coordinate 
data transmission with scheduled uplink and 
downlink ground station contacts. The DTN 
bundle protocol provides “persistent storage” 
allowing data to be held within the network 
pending future data link contacts. This enables the 
decoupling of data generation from contact 
schedules. To demonstrate this capability, the test 
plan included the transfer of contact schedules, 
during non-contact periods, from the Science 
Operations Center (SOC) to EO-1. 

• Recovery of C&DH housekeeping data . Since 
2006, the EO-1 Housekeeping data stored between 
ground contacts has been lost due to a failure in the 
(C&DH) Solid State Recorder (SSR). Using DTN 
“persistent storage” and the priority function, the 
plan included recovery of some housekeeping 
packets. 

• Provide automated store and forward of satellite 
data. As mentioned earlier, hyperspectral and other 
imaging satellites produce large volumes of data. 
Typically, the data is transmitted to ground stations 
at very high data rates (i.e. 150 Mbps). The data is 
usually captured at the ground station and 
forwarded later at a lower rate via terrestrial data 
links or physical media such as data tapes. This 
activity demonstrated the DTN capability to 
automatically and reliably store and forward 
satellite data via custody transfer between the 
spacecraft and the Mission Operations Center 
(MOC). 


The demonstration included three phases executed over a 
total of 6 y 2 days, of which 3 l A were in December, and 3 
days were in February. Altogether there were 14 contacts 
available with approximately six to seven minutes of each 
pass available for testing. Only one contact was via the 
Wallops Ground Station (WGS). Phase 1 was the initial 
integration of the DTN code into the EO-1 onboard software 
and the EO-1 MOC. The goal was to verify the basic 
communications function of receiving/sending DTN 
bundles, and contact schedules, between the flight and 
ground MOC DTN nodes. Data exchange included both 
ASCII text and files. This also provided insight into 
infusion of DTN into existing flight and ground systems. 
Phase 2 tests were designed to demonstrate the automated 
store and forward benefit using the custody transfer and 
priority functions of DTN within a three node network. As a 
side benefit particular to EO-1, recovery of EO-1 
housekeeping data were also included. This phase provided 
insight into potential benefits of the DTN technology. 
Phase 3 tests were a repeat of Phase 2 but with the addition 
of a DTN node WGS. 

This created a four node network and gave insight into 
infusion of DTN into ground station operations. The full 
network configuration is illustrated in Figure 1. 




into the consequential LTP acknowledgement (ACK) traffic 
on the forward link. 

Phase 2 demonstrated the ability of DTN to store and 
forward housekeeping data. This capability ‘conceptually’ 
eliminates the need for an onboard housekeeping solid state 
recorder, since data is persistently stored until custody of 
data is accepted by another DTN node. It also incorporated 
the third DTN node at the science operations data center. 
Contacts were either manually started or uploaded as file 
transfers at certain points throughout the test. Phase 2 
targeted the benefits defined earlier including: 


Figure 1: EO-1 Demonstration Configuration 

Data Flow and Protocols 


All EO-1 DTN network nodes use the Bundle Protocol (BP) 
at the network layer. However, different transport layers 
were used. For the space to ground link, EO-1 and the MOC 
implemented Licklider Transport Protocol (LTP). LTP 
provides reliable transfers point to point from the EO-1 
Flight DTN node to the MOC DTN node. LTP segments 
were sized to fit within the data field of the existing EO-1 
data link layer units, which are Consultative Committee for 
Space Data Systems (CCSDS) Advanced Orbiting Systems 
(AOS) frames on the downlink. For the uplink, the LTP 
segments were inserted in the CCSDS command packet data 
field. In Phases 2 and 3, the Transmission Control Protocol 
(TCP) was the transport protocol of choice for all ground 
links. TCP provides a reliable transport between the EO-1 
MOC and the Science Operations Center (SOC), as well as 
the WGS MOC and EO-1 MOC. The protocol stacks are 
illustrated in Figure 2. 
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Figure 2: EO-1 Protocol View 
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Test Results 

Phase 1 verified the communication links as well as some 
functionality of DTN. Impact to operations was also 
observed. In particular, ground commands, text strings, and 
files were transferred between the flight node and the 
mission operations center. During the file transfer test (from 
flight node to ground node), the file was received by the 
MOC DTN node despite the fact that only 16-20% of the 
LTP segments were forwarded from the ground front-end 
equipment to the MOC DTN node. This was enough to 
complete the file transfer and illustrated the benefit of DTN 
as compared to file transfer without DTN, where the file 
transfer would have been incomplete. It also gave insight 


Decoupling of schedule and telemetry/command: To 

demonstrate this capability, the test plan included the 
transfer of contact schedules, during non-contact periods, 
from the EO-1 SOC to the EO-1 spacecraft. The schedule 
was transferred autonomously without operator intervention 
and was executed on-board and on the ground DTN nodes to 
control link availability. On the downlink, EO-1 
housekeeping data was transferred to the MOC. 
Housekeeping data were collected during the non-contact 
period and prioritized on the downlink once a contact began. 
No support from operations personnel was required. 

Recovery of Housekeeping data: During ground contact, 
the data generated is called “real-time”. This real-time 
housekeeping data are sent by the formatting application as 
higher priority, while the housekeeping data collected during 
the non-contact time are sent with a lower priority. This 
demonstrated the DTN data prioritization capability and the 
recovery of ‘out of contact’ stored housekeeping data. 

Automated Store and Forward: Specifically, the contact 
schedule file was transferred from the SOC DTN node 
through the MOC node to the Spacecraft node using custody 
transfer. Custody transfer enabled the SOC to send data to 
the spacecraft (nominally this would be the science 
applications) outside the contact period. Quality of Service 
(QOS) specified both forwarding and delivery confirmation 
of the data. 

Phase 3 incorporated a fourth DTN node at the Wallops 
Ground Station. This node simulated a Ground Station 
DTN node that facilitates data transfer with the flight DTN 
node to demonstrate custody transfer capability. The 
concept for the Wallops ground station is to “tee” off the S- 
band telemetry stream and send to a co-located DTN 
Workstation. This DTN node parses the incoming telemetry 
stream and extracts and processes LTP data segments. It is 
also connected to the MOC ground system machine to 
facilitate uplink messaging with the flight DTN node. 
Phase 3 was mostly successful. The ability to initiate a 
contact via DTN command from the Wallops DTN node 
verified the forward link communications. The Wallops 
DTN node successfully received telemetry (in the form of 
CCSDS Virtual Channel Data Units or VCDUs) from 
Wallops Packet Telemetry Processor (PTP) and successfully 
extracted the packets. However, it did not recognize them as 
LTP packets so did not pass these along to the DTN 
software. Therefore, the Wallops DTN node did not process 
any incoming LTP data from the spacecraft, so no 
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Housekeeping packets or ACKs or CUSTODY TRANSFER 
messages were processed by the Wallops DTN node. Since 
there was only one contact within the test period that 
included Wallops, there were no more opportunities to fix 
and retry this test. Post-demo analysis, however, revealed 
the problem to be a software bug in the support software. 
Once corrected, the flight data were replayed through the 
ground system elements and the data were successfully 
received by the EO-1 MOC and SOC. 

Summary 

The principal DTN test objectives were demonstrated and 
provided the beginnings of answers to the benefits of the 
protocol to Earth Science missions. BP/LTP worked not 
only in the nominal or expected conditions, but also enabled 
the receipt of a file, which would otherwise have been lost, 
during unexpected anomalous conditions. Store and 
forward, as well as custody transfer were clearly beneficial 
for autonomous operations. Integration of DTN into the 
Wallops Flight Facility Ground Station was extremely 
simple and straight-forward due to the well-defined 
interfaces of the ground station equipment and the front end 
processor. Using standard protocols for these interfaces was 
key. When bundles were expected but not received, the 
operations and test team felt a lack of insight into the flight 
DTN software. Given the lack of DTN status telemetry, it 
was difficult to know what was going on or where the 
problem lay. Improvement in this area would be beneficial 
to mission operations acceptance, but this is easily corrected 
with enhancement of the protocol code. The use of DTN in 
the recovery of EO-1 telemetry clearly shows beneficial 
side-effects and an unexpected use of the technology. 

Security and firewall problems occur if there is a need to go 
outside the mission network. Waivers were needed to send 
data from the EO-1 MOC to the SOC due to the fact that 
they were on different networks and thus had different 
policies. Depending on the configuration of the network(s) 
involved, this may be a “long-lead” item. 

As mentioned earlier, this demo was subject to the 
constraints of all flight software and thus had to adhere to 
policy and system engineering requirements. Policy 
requirements may include things such as: specifying one 
telemetry packet which contains the spacecraft-to-MOC 
DTN data unit; specifying one command packet which 
contains the MOC-to-spacecraft DTN data unit; specifying 
one command packet which contains administrative 
commands sent to the spacecraft DTN by the MOC; or 
limiting transmission of DTN data unit packets to an interval 
of given length and which begins when the Flight Operations 
Team authorizes the start of transmission. System 
engineering requirements were met by using DTN’s LTP 
protocol to set a maximum return and forward link 
utilization. LTP provides several useful side effects, 


including reliable bundle transfer and segmentation/packing 
of large or small bundles into packets sized for convenient 
transfer through the normal command/telemetry channels. 

Overall, insight was gained given the limited amount of 
actual test time on the EO-1 spacecraft, and because the 
planned tests encountered some obstacles. Information 
regarding anomalous situations was gathered as well. A 
window into future benefits was opened. These may include 
increased flexibility for onboard product generation. The 
current interface mechanism between the ground agent and 
the onboard science software requires significant overhead 
in terms of onboard processing, ground processing, and 
overall systems engineering. Due to the constraints of the S- 
band link/bandwidth, considerable effort is spent performing 
systems engineering of onboard analysis and onboard 
generated products. Operational use of DTN would free the 
software from micro -managing this data stream by 
automatically managing data custody and prioritization. It 
should be noted that for this demo, the DTN code was not 
fully integrated with the existing science application code; 
rather it took the place of the science application software. 
This was due in part to resources available for the demo, as 
well as a risk-reduction to prove the technology without 
impact to the spacecraft. 

One final observation that aligns with the IRIS demo 
described later in the following section is the potential for 
increased flexibility for sensor web applications 
development. All of the, ten or more, sensor web campaigns 
demonstrated by EO-1 rely on static, pre-developed 
campaigns requiring ground personnel to identify the 
source/trigger and response assets in the sensor web. An 
onboard DTN node could enable EO-1 to participate in a 
publish and subscribe fashion with nodes dynamically added 
to the DTN. This opens up a whole range of possible 
triggers and response assets that only need publish alerts to 
the sensor web DTN network. Any node subscribing to the 
relevant class of messages can then respond, enabling a true 
sensor web paradigm of information sharing and enhanced 
earth observation. 

3. IRIS Demonstration 

Goddard Space Flight Center demonstrated a collaborative 
earth science sensor web scenario in the Communications, 
Standards, and Technology Lab (CSTL), utilizing Cisco’s 
IRIS payload on Intelsat- 14. IRIS is the first router in 
geosynchronous orbit and served as an IP relay in this 
sequence of events. The primary objective of this 
demonstration was to examine advantages of Bundle 
Protocol (BP) and Internet Protocol (IP) relay use in 
collaborative science missions. The thought being that 
automated storing, forwarding, and routing functions within 
a network would reduce the latencies between collaborative 
science assets. 
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Scenario 2: Multi-Node Internetworking for In-Situ Sensor Networks with Satellite Backhaul 
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Figure 3: IRIS Collaborative Science Demonstration 


The details of the test scenario are depicted in Figure 3. The 
data flow is from right to left. It shows an earth science 
mission spacecraft, Flight System 1 (FS1), transferring 
bundles containing data, such as event alerts, to in-situ 
sensors on the ground. In this instance, a bundle directs the 
in-situ sensor to take a look at an interesting event observed 
from Flight System 1 . The data are forwarded at each node, 
from Flight System 1 to the FS1 Mission Operations Center 
(MOC), then to the Science Collaboration Center (SCC), via 
IRIS to the Sensor MOC. The Sensor MOC forwards the 
data to the sensors, which is the desired action to perform. 
The Sensor MOC in Figure 3 is also known as CSTL 
Advanced Portable Communication System (CAPCS). If 
any link is disrupted, the data are stored at each node until 
the link becomes available. Bundles were transferred with a 
nominal data rate of approximately 170 Kbps. Higher peak 
rates were seen when the IRIS radio frequency link was 
reconnected and queued bundles flowed at the maximum 
achievable rate. 

Data observed from the sensors are then sent back to the 
Science Collaboration Center (SCC). At the SCC several 
activities take place. The in-situ sensor data are written to 
SCC disk storage for processing by ILIADS. ILIADS is a 
visualization software package that is acting as a piece of 
ground support equipment and a facet of the overall 
collaboration model. Additionally, the sensor data may be 
combined with the primary observation data from Flight 
System 1 for collective science applications. Or perhaps 


Flight System 1 could enhance its operation based on 
measurements received from the in-situ sensors. 

In the CSTL the scenario was executed with science 
’’events” being generated asynchronously by toggling a 
switch on the Flight System 1 (FS1) ’’flight computer”, 
which in turn generated the event bundles. When a link 
between the Flight System 1 and FS1 MOC was unavailable, 
these event bundles are queued on Flight System 1 . Over a 
period of forty-three minutes and one second, when a link 
was available, these event bundles were down linked from 
Flight System 1, forwarded via IRIS to CAPCS, and then on 
to the sensors. In this demonstration, the in-situ sensors are 
Android Google phones, a collection of weather sensors, and 
a camera. 

In order to emulate a variety of links with different contact 
periods, the link between Flight System 1 and the MOC is 
varied on for five minutes, off for five minutes, then on for 
ten minutes. The contacts were driven by the flight 
software scheduler, which was programmed with the contact 
duration and interval between contacts. The flight software 
scheduler controlled both the BP/LTP contact graph routing 
parameters and the CCSDS File Delivery Protocol (CFDP) 
file transfer enable/disable. The IRIS link was disrupted 
twice during the test. This was done by turning off power to 
the modem in the portable terminal. When the IRIS to 
CAPCS link was unavailable, bundles were stored in the 
SCC until the next available contact. 
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In response to the event bundles received from Flight 
System 1, bundles containing GPS coordinates were sent 
from the Google phones back to Flight System 1 . Hence, the 
rate of bundles sent from the Android Google phones varies. 
The bundles originating at the Google phones also 
experienced disruptions of the IRIS link and FS1 MOC to 
Flight System 1 link. Bundles are queued in the Sensor 
MOC when the IRIS link is down. Bundles are queued in 
the SCC when the FS1 MOC to Flight System 1 link is 
unavailable. The bundles sent from the Google phones to 
CAPCS back to the science collaboration center were sent 
using Bytewalla, an implementation of DTN2 for Android. 

Throughout the entire demonstration, weather station data 
and camera images are sent multicast back to SCC and to the 
node in Raleigh, North Carolina. The weather station is 
sending pressure, temperature, wind speed, measurements 
throughout the duration of the test. The weather station data 
are sent using user datagram protocol (UDP) Multicast. The 
weather station sends an approximately 630 Byte weather 
report bundle every 5 seconds. The camera sends an 
approximately 32 Kbyte JPEG bundle every 3 seconds. 
There was an additional data stream throughout the test 
between the Voice Over IP (VOIP) phones connected to 
CAPCS and the SCC. This data is sent using Real Time 
Protocol (RTP). 

There is also a VOIP phone associated with CAPCS and the 
FS1 MOC. This was used randomly throughout the test to 
perturb the protocol mix and add complexity to the test. 

It should be noted that BP/TCP was used for the space link 
between IRIS and the ground centers due to the fact that 
there was no expectation of maximum link utilization. For 
maximum link utilization on space links, LTP would be the 


logical choice. 

Results 

A collaborative science sensor web can be done without an 
IP relay, like IRIS; however, it would not be as efficient. 
Figures 4 and 5 compare data flows using IRIS, without 
routing capabilities, as the backhaul between the Sensor 
MOC and the SCC and using IRIS as an IP relay. Solid 
lines in the diagram refer to the data path with an IP relay 
and dashed lines refer to the data path without an IP relay. 
For clarity, Figure 4 illustrates the data path from the Flight 
System to the Sensor MOC while Figure 5 displays the data 
path of in- situ sensor data from the sensors to the SCC. 

In Figure 4, data flows from Flight System 1 to FS1 MOC 
then to the SCC. These two steps, (1) and (2), are the same 
with or without an IP relay. The differences are seen from 
step (3) onward. If Flight System 1 wants to send its data to 
both the node at RTP and the Sensor MOC it can do that via 
multicast with an IP relay. From the SCC, the data would 
go to IRIS (step (3)) and then to both North Carolina 
Research Triangle Park (RC NTP) (4) and the Sensor MOC 
(4) simultaneously. So, data is sent with an IP relay from 
Flight System 1 to RC NTP and the sensor MOC in four 
steps. Without an IP relay, multicast capability is not 
available so the path from SCC to both NC RTP and the 
sensor MOC changes. From SCC the data must go to IRIS 
via KU1 band (3) to Sensor MOC (4). The same data must 
also go from SCC to NC RTP node via KU2 band (5, 6). 
Hence, the data path without an IP relay requires two 
additional hops. 
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Figure 4: Path of Flight System # 1 data for IRIS Scenario with and without IP relay 
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In figure 5, the node at RTP and the sensor MOC are also on 
two different frequency bands, Kul and Ku2. A non relay 
satellite transponder does not support cross beam 
communication. However, this functionality is available 
with a router in space. Using the IRIS, the weather station 
and Google phone data would go to the Sensor MOC (1) and 
then directly to both RTP and SCC using multicast (2, 3), 
taking a total of three hops. This is shown with solid black 
lines in the Figure 5. In order to get weather station data to 
both RTP and the SCC node without cross beam 
communication, the weather station data would have to 
travel the same route from Sensor MOC (1), then to SCC via 
IRIS Kul (2,3) to get to the SCC Node, but would then 
have to be sent back up on Ku2 beam via IRIS (4) to get to 
the RTP node (5), resulting in an additional two hops and a 
delay of two round trip times. This is illustrated in Figure 5 
with the dashed black lines. 

Summary 

Results indicated potential advantages of using Bundle 
Protocol for a collaborative earth science mission. This 
scenario allowed the latency associated with sensor web 
alerts and collaborative science to be assessed. Nodes were 
able to store and forward event data in the presence of 
disrupted links without data loss and without operational 
intervention. The latency between the event detection at 
Flight System 1 and notification at the sensors was small. 
The IP relay reduced the number of hops necessary to 
communicate between the nodes collaboratively, which in 


turn helped to improve the overall latency in the system. 
Multicast data transfer and cross-beam communication were 
also demonstrated via the IP relay. While real-life mission 
results will vary depending on the number of nodes and 
contact periods, this demonstration clearly showed the 
potential for DTN to enable an environment where alerts are 
autonomously ’’published” throughout a web system and 
users ’’subscribe” to the alerts/events and take action 
accordingly. The autonomous store and forward capability 
of DTN along with a networked architecture enables the 
science community to receive alerts quickly and respond 
accordingly. 

4. TDRSS Demonstration 

As part of the DTN Readiness Program, GSFC performed 
several DTN/IP protocol communication tests with the 
TDRSS spacecraft. The goal of these tests was to observe 
how the internetworking protocols, namely the Bundle 
Protocol (BP) and the Internet Protocol (IP) perform when 
communicating via asymmetric TDRSS links with uni- 
directional periods. This is a typical Earth Science/Low 
Earth Orbit (LEO) mission configuration. The CSTL was set 
up to emulate the conditions of a multiple access user and a 
S-band single access user of TDRS. Both asymmetric and 
intermittent simplex links were exercised. 
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Figure 6: TDRS Demonstration Scenario 


There were three network nodes: the spacecraft, the ground 
station, and the mission control center. Files were 
transferred, via CFDP, between the spacecraft and the 
mission operations center using the TDRS link. This test 
scenario is executed with the protocol stack, CCSDS File 
Delivery Protocol (CFDP) Class 1/BP/LTP/IP/AOS Encap, 
which is depicted in Figure 6. CFDP Class 1 provides 
unreliable file transfer. BP optionally uses “custody 
transfer” for its data units to supply reliable transfer. CFDP 
class 1 was selected for the BP/LTP stack since LTP already 
ensures the reliable transfer of files. Class 1 CFDP and LTP 
would be redundant. CFDP was configured such that the 
retry count was never exhausted. The details on the test 
scenario are depicted in Figure 6. This is an earth science 
mission spacecraft that is transferring a 1.6 Megabyte file to 
the ground via TDRS East. A 1.6 Megabyte file was 
arbitrarily selected so that on the 128kbps link a reasonable 
amount of data points could be captured for each file 
transferred. The file is then forwarded on to the Mission 
Control Center (MCC). The file is transferred via 
asymmetric TDRSS links with uni-directional periods. 


Results 

The graph in Figure 7 is a sample of what was observed 
during the TDRS testing. The graph is depicting a MA 
TDRSS user with asymmetric data rates and simplex links. 
The return link is 64 Kbps and the forward link is 18Kbps. 
The period begins with return link only followed by an 
intermittent forward link for the remainder of the test. From t 
= 0 through t = 825, the forward link is down. File segments 
are delivered until the maximum outstanding queue depth is 
reached. At 825 seconds, forward link is started, the 
protocol handshakes complete, and transfers resume. The 
erratic rx-data rate seen after 850 seconds is unexplained and 
so far unduplicated. 

There was an anomaly observed with LTP that could not be 
duplicated in follow-up testing. The LTP state machine did 
not resume nominal operation when the radio link 
transitioned from return link only to full duplex. The LTP 
handshake for the outstanding transfers did not occur and the 
ground-side LTP engine was ’’stuck” not acknowledging the 
outstanding transfers, which held up the ’’spacecraft” sender 
from starting new ones. However, this stack also 
successfully transferred files when the TDRSS link was 
replaced with a land-line link. So the anomaly may well 
have been a configuration issue and not a protocol issue. 
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Figure 7: Sample result from ION-TDRSS Demonstration 


A retest was done in the CSTL lab to try to reproduce the 
LTP state machine problem that occurred during the TDRSS 
ION testing. The retest used CFDP Class 1 over ION 
(BP/LTP/UDP/IP) which is identical to the protocol stack 
from previous TDRSS ION testing. This retest was done 
using a hard-line connection and the anomaly could not be 
recreated. During the retest depicted in Figure 8 the forward 
link is disabled for one, two, three, and ten minutes. Each 
time LTP transfer resumes after each interruption. The test 
begins with the forward link down from 70 seconds to 
approximately 120 seconds. The LTP state machine 
problem is not seen during this series of events. 


Summary 

Earth Science and LEO missions have some unique 
characteristics like simplex and asymmetric link rates. An 
internetworking protocol that could handle these 
characteristics would be advantageous to earth science 
missions. Missions would be provided with the tools such as 
rate buffering, autonomous routing, and storing and 
forwarding to handle this dynamic environment. 

Additionally, the TDRSS ION test demonstrated the 
performance of file transfer (CFDP) over 
BP/LTP/UDP/IP/AOS-Encap protocols stacks satisfying 


several requirements in the CCSDS DTN in Space Green 
Book. [2] Some of the requirements of note are related to 
file transfer, simplex links, and Quality of Service. 
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Figure 8: Sample output of ION-TDRSS retest 


5. Summary 

Collectively, the demonstrations provided empirical 
evidence that backs up claims that DTN can benefit an Earth 
Science Mission or any single flight and ground based 
system with satellite links. IRIS illustrated the potential for 
a reduction in latency as a result of a networked architecture 
and DTN usage in collaborative science scenarios. EO-1 
showed the DTN store and forward function as an enabler 
for sensor webs and improved operations. Opportunities for 
collaboration or observation that were forgone as a result of 
the short response time needed could be taken advantage of 
with DTN usage. Using TDRS, a simple test showed DTN 
as a potential solution for issues surrounding asymmetric 
links and disparate space/ground links. Custody transfer 
enabled file capture on the ground that would not be possible 
with today’s tools. And as is seen quite often, indirect 
benefits are uncovered, as was the case with the EO-1 
recovery of housekeeping data. Operations and ground 
station infusion provided valuable feedback for future 
mission infusion. While much was learned with these 
demonstrations, further investigation will be needed to hilly 
understand the benefits of DTN to Earth Science missions 
and space internetworking. 
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6. Future Work 

Earth Science Missions are increasing the amount of science 
data being returned to Earth constantly. Decadal Survey 
missions [3] will have hundreds of gigabits of data per day 
that must be down linked. Further testing should be done to 
observe the DTN protocol working in mission like scenarios 
at higher data rates. Analysis should be done to determine 
challenges and benefits associated with DTN protocols at 
higher data rates. 
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